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Hovodb/:^^.' •• •• RLC Window Size Reconfiguration 



FIEIfD OF THE naVBBPPION 

The present invention relates to RLC window size 
5 reconfiguration in Wideband Code Division Multiple Access 
(W-CDMA) standard as defined by 3GPP. 

BlkCKGROUNX) OF THE XISVEtlTXON 

RRC Signalling currently support reconfiguration of RLC 
parameters during a connection, e.g. with a RADIO BEARER 
10 RECONFIGURATION message. However, the actions related to a 
reconfiguration, particularly a reduction of the RLC window 
size, are not explicitly specified in the document 3GPP TS 
25.322. The following will highlight why the reconfiguration 
of the RLC window size is highly beneficial. 

15 Consider a UB with UB reference class 384 Kbps. According to 
the doc^ent 3GPP TS 25.306, typical RLC capabilities for 
this UE class is 50 Kbyte UE memory and idaximum 6 AM RLC 
entities. Thus, the UE can potentially use 3 parallel PS 
RABs. The focus of the following discussion will be the case 

20 with 2 simultaneous PS RABs, e,g- 2 parallel interactive 
RABs or one interactive and one streaming RAB. 



When the first PS RAB is setup, UTRAN can not know if a 
second (or third ) PS RAB will be setup in the future. As 
the RLC window size of the first PS RAB can not be reduced 
25 when a subsequent RAB is setup, UTRAN need to taJce into 
account the memory usage of RABs that may potentially be 
setup in the future- To allow, e.g., 2 parallel PS RABs, 
UTRAN can only allocate half of the available tJE memory for 
the first PS RAB, which leads to a reduced performance. 
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Assuming, e-g., that the window size for SRB2-4 luxs been 
configured to 128, whic2h is the only choice with default 
configurations if the UE has made handover from GSM. If the 
RliC window size could be reduced at reconfiguration, UTRZ^ 
5 could now allocate the whole remaining memory for the first 
PS RAB, e,g- a window size 512 in downlink and 256. in 
uplinkr resulting in a total memory usage of 42 kbyte. If a 
second PS RAB is later setup the window sizes could be 

■ 

reconfigured to suit the number of simultaneous RABs. 
10 However, since the potential memory usage of a second PS RAB 
needs to be considered already when the first PS RAB is 
setup, the RLC memory can only be configured to, e.g. , 255 
in downlink and 128 in uplink, which results in a worse 
performance . 

* 

15 Especially for higher data rates, e.g* 384 kbps, the RLC 
window size has a significant impact on the perfonr.ance in 
terms of delay/ throughput , Since 2 parallel PS RABs may only 
be used in a fraction of the PS connections this implies 
that a large amount of the UE memory is xinused for most UEs 

20 and the throughput for PS connections unnecessarily low. If 
3 parallel PS RABs are considered^ the problem is even more 
severe, since UTRAN can only allocate one third of the 
available UE memory when setting up the first PS RAB. 

:'r 25 

: ' BR±EF DESCRXPTXON OF THE DRA19ZNG8 

■ • 

Figure 1 shows an exaitple of an RLC window size reduction. 
The grey PDUs are transmitted/ received and the white PDUs 
are not yet transmitted/ received. 
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DESCRXPTXON OP THE XX9VEHTXOH 
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The present invention refers to methods for reconfiguring 
the RtiC window size. Since the reconfiguration of RLC window 
size is supported according to the docixment 36PP TS 25.331 
and the modelled RLC interaction with higher layers allows 
for a reconfiguration of any RLC parameter it can be argued 
that both increase and decrease of the configured RLC window 
size is already supported in R99. However, in particular 
when the window size is decreased the UE actions are not 
unanibiguous . It is therefore proposed to clarify the actions 
related to a decrease of the window size as described below. 
Note that an AM RLC entity has both a transmitting and a 
receiving side, i.e. both the receiver and tran.smitter 
behaviour is applicable for the UE. 

In Figure 1 an exaxnple of a window size reconfiguration is 
shown where the window size is reduced from 16 to 8 . In case 
a) the transmitter and receiver windows cover tlrie same 
sequence n\iniber range and in case b) the receiver window is 
advanced further than the transmitter window due to that a 
status message acknowledging PDUs 0 and 1 has not yet been 
sent, or has been sent but lost over the air interface » 

The following will now describe a first embodiment of the 
solution according to the present invention: 

Reduction of the receiver window: When the receiver window 
is reduced, some of the PDUs received in the old receiver 
window may end up being outside the new receiver window. In 
order to free memory it is proposed that these PDUs shall be 

ft 

discarded in the UE and treated as not being received. This 
implies that UTRAN needs to retransmit these PDUs after the 
reconfiguration but this is considered to have little dLmpact 
on the performance. 



•03 04/07 MAN 13:03 I'AX +46 8 7641514 * ERICSSON ERA ZP PRV AVGIPTER 

+46 8 7641514 

4 



''^^''^-'ftfeduction of the transmitter window: When the transmitter 
window is decreased, some of the PDUs transmitted in the old 
transmitter window may end up being outside the new 
transmitter window. The first solution that comes to mind is 

5 to discard these PDUs from the transmitter in order to free 
memory- However this may imply the following consequences: 



1) Peirmanent data loss: If these PDUs are discarded/ they 
can not be retransmitted which would lead to a permanent 
data loss. Ihis could potentially be acceptable for HBs but 

10 would mean that it is not possible to reduce the window size 
for SRBs. As discussed in relation to the default 
configurations used at handover from GSM it wculd be 
beneficial to be able to reduce the window size from the 
value 128 used in the default configuration to a lower value 

15 to free memory. 



2) Errors in protocol operation: The discarding of PDUs in 
the transmitter may lead to protocol errors. Consider case 
b) in Figure 1 above. If the transmitter would discard PDUs 
outside the new transmitter window it means that PDUs 8-15 
20 are discarded and can not be retransmitted- However, due to 
that the receiver window in case b) is advsinced further than 
the transmitter window, a PDU with SN=8 is within the new 
receiver window. Tf this PDU can not be retransmitted the 
RLC protocol has stalled. 

25 It is therefore proposed that all PDUs that €*re not 
positively acknowledged are kept in the buffer. "Ehis iiigplies 
that if UTRAN negatively acknowledges some of the PDUs 8--15 
in the example after the reconfiguration, the UE .must be 
prepared to retransmit the PDUs. 
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This solution inq5>lies that the KLC buffer memory ^required 
for the reconfigured RLC entity momentarily can.be as high 
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as the old KLC window indicates . This could potentially mean 
that there is not enough free memory to segment all incoming 
SDUs for all RLC entities • It is therefore proposed to 
specify that if the mCTiory capability of the DE is exceeded, 
5 the UE does not need to segment SDUs received from upper 
layers. This means that the memory required for all 
transmitter buffers in the UE will not require more memory 
than needed to support the configured RLC windows at any 
time . 

« 

10 The interaction between RLC and higher layers when data can 
not be transmitted (e.g. due to that the RLC window is full., 
or the RLC ^tity is suspended) is not specified- However, 
some form of flow control must exist also in, e-g., existing 
R99 UE implementations to prohibit a higher layer 
15 application to submit data to RLC in these situations. 

The first embodiment is rather straightforward but might not 
work well if the in-sequence delivery is not configured. If 
for example an SDU is present in PDUs 11--12 in case b) this 
SDU may already be delivered to higher layer wlien the 
20 reduction of the RLC window size occurs. After the 
reconfiguration these PDUs will be retransmitted by the peer 
entity and consequently a duplicate of the SDU will be 
delivered to higher layers. The retransmission of PEUs with 
sequence nuiribers outside the old transmitter window also 
25 cause additional delay, 

0 

Therefore, as a second embodiment of the present invention, 
a more advanced window handling can be specified as 
described below: 
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Reduction of the receiver window: When the receiver window 
is reduced, all PDUs in the receiver buffer are kept, even 
if these PDUs are outside the new receiver wind<Dw- The 
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. .,...\ j-eceiver window is advanced according to the normal rules 
described in 36PP TS 25.322. 

* 

Reduction of the transmitter window: When the transmitter 
window is reduced, all PDOs in the transndtter buffer are 
5 kept, even if these PDUs are outside the new transmitter 
window- The transmitter window is advanced according to the 
normal amies described in 3GPP TS 25.322. 



Memory handling: Since all PDUs are kept in the RLC buffers 
at reconfiguration, it is possible that PDUs transmitted 
10 and/ or received on the new RAB temporarily causes the UE RLC 
buffer capability to be exceeded. To handle the possibility 
that the UE buffer memory may not be sufficient to handle 
all AMD PDUs during an initial time after the 
reconfiguration, the following behaviour is proposed: 



* 



15 Before a SDU received from upper layers is processcsd or a 
received AMD PDU is stored, the UE must check that the RLC 
buffer memory is sufficient to store the following PDUs: 

In the receiver side: AMD PDUs with SW in the interval 
[VR(R)< SN< VR(H)1 for all RLC AM entities 

20 In the transmitter side: AMD PDUs with SN in the interval 
[VT(A)< SN< VT(S)] for all RLC AM entities 



If the processing of a SDU received from upper layer leads 
to over-allocation of the UE buffer memory according to the 
signalled UE capability, the SDU shall not be processed. 

25 If the reception of an AMD PDU leads .to over-- allocation of 
the UE buffer memory according to ^ the signalled UE 
capability, the PDU shall be ignored. This check only needs 
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' " ■ to be performed if the SN of the received PDU causes VR(H) 
to be increased. 

In this way it is guaranteed that a UE always can receive 
AMD PDUs with SN in the interval IVR(R)< SN< VR{H) ] for all 
5 RLC AM entities (i.e. retransmissions), which is needed to 
prevent • potential deadlock situations. If this is not 
guaranteed it is possible that the UE ignores all received 
PDUs cind it is not possible to get out of the stall 
situation. 

10 Two embodiments for handling the reduction of the configured 
RLC window size has been described. The first enibodiraent is 
straightforward but only works if the in-sequence delivery 
is configured. This embodiment also requires that tae PDUs 
outside the new RLC window are retransmitted after the 

15 reconfiguration which ixnplies a larger delay for the user 
data. The second exnbodiment requires more advcoxced m^nory 
handling but handles also the case where in-sequence 
delivery is not config\ired and avoids retransmissions of 
PDUs after the reconfiguration- 
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